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Adequate  Planning  for  Acquiring  Sufficient  Documentation  about 
and  Rights  in  Software  to  Permit  Organic  or  Competitive  Maintenance 

Pamela  Samuelson 


Abstract.  Both  the  DoD  and  industry  have  significant  concerns  regarding  maintenance  and 
enhancement  of  software.  The  DoD  wants  to  be  certain  it  will  be  able  to  maintain  and  enhance 
software,  and  where  cost  effective,  to  compete  maintenance  of  software.  Industry  wants  ensure 
that  its  proprietary  interests  will  be  adequately  protected.  This  paper  will  explore  possible  ways  in 
which  both  groups*  interests  might  be  satisfied. 


Introduction 

The  Department  of  Defense  (DoD)  is  a  major  consumer  of  software.  This  software  is  used  as  a 
vital  component  of  many  systems  ranging  from  those  which  perform  relatively  simple  functions, 
such  as  intra-office  communications  and  word  processing,  to  sophisticated  software  which  is 
embedded  in  major  weapons  and  defense  systems.  The  procurement  of  software  is  an  ongoing 
rather  than  discrete  event.  This  is  because  software  must  be  maintained,  and,  as  needs  change, 
enhanced. 

Maintenance  and  enhancement  of  software  is  often  a  problematic  and  expensive  undertaking.  As 
a  result  of  issues  arising  under  the  copyright  laws  and  DoD  acquisition  regulations,  as  well  as 
other  practical  problems,  the  DoD  quite  often  finds  that  it  does  not  possess  adequate  documen¬ 
tation,  software  tools,  and/or  intellectual  property  rights  to  perform  necessary  maintenance  and 
enhancement  functions,  either  organically  or  through  competitive  reprocurement.  As  a  result,  the 
DoD  may  be  left  in  the  position  of  having  to  return  to  the  original  contractor  whose  possession  of 
needed  documentation  and/or  rights  puts  the  contractor  in  a  sole  source  position  as  to  DoD 
maintenance  and  enhancement  needs.  This,  of  course,  is  a  position  DoD  would  prefer  to  avoid, 
for  both  economic  and  political  reasons. 

This  paper  explores  the  legal,  regulatory  and  logistical  problems  related  to  software  maintenance 
and  enhancement.  Some  potential  solutions  for  acquiring  sufficient  documentation  and  intel¬ 
lectual  property  rights  to  allow  for  organic  and/or  competitive  reprocurement  for  maintenance  and 
enhancement  are  offered. 

A.  The  Hybrid  Character  of  Software 

To  begin,  it  is  important  to  understand  the  hybrid  nature  of  software.  Software  in  its  machine- 
readable  form  has  some  characteristics  of  hardware  and  some  characteristics  of  technical  data. 
This  hybrid  character  has  made  It  difficult  to  categorize  exactly  how  software  should  be  acquired, 
and  then  maintained  after  acquisition:  should  it  be  treated  like  hardware  or  like  technical  data,  or 
as  a  distinct  item  altogether?  This  section  is  intended  to  explore  ways  in  which  this  hybrid 
character  may  affect  planning  for  software  maintenance  and  enhancement. 


1 .  Software/Hardware 


Software  is  like  hardware  in  that  it  causes  machines  to  do  things.  Software  is  in  fact  merely  a 
replacement  for  hardware  components  that  could  otherwise  perform  the  same  function.  Software 
is  often  embedded  in  hardware  and  part  of  an  overall  hardware  system.  Like  hardware,  software 
can  often  serve  as  a  tool  for  creating  other  items,  including  new  software.  And  like  hardware, 
software  will  require  maintenance  work  from  time  to  time  to  operate  properly,  although  the  type  of 
maintenance  which  software  requires,  such  as  fixing  a  "bug"  or  making  an  enhancement,  differs 
in  many  respects  from  the  more  traditional  forms  of  maintenance  required  by  hardware. 

Software  is  unlike  hardware,  however,  in  many  other  ways.  Software  is,  for  example,  less  difficult 
and  less  expensive  to  replicate  than  is  hardware.  Once  the  first  copy  has  been  produced, 
software  can  be  almost  endlessly  replicated  at  little  cost  regardless  of  how  complex  the  code  is. 
One  of  the  consequences  of  this  is  that  the  government  tends  to  think  that  additional  copies  of 
software  ought  to  be  deliverable  at  a  very  low  cost,  whereas  industry,  which  is  concerned  about 
recouping  its  research  and  development  costs,  regards  additional  sales  at  higher  price  levels  to 
be  necessary  to  make  the  software  industry  viable.  Because  of  the  ease  of  replication,  industry 
representatives  often  regard  the  sale  of  software  as  more  akin  to  the  sale  of  a  production  facility 
rather  than  the  sale  of  a  single  product  (as  if  one  bought  a  General  Motors  factory  when  one 
bought  a  truck  produced  by  GM).  Another  consequence  of  this  low-cost  replicability  is  that  the 
software  industry,  for  the  most  part,  tends  to  make  its  products  available  only  on  a  highly  restric¬ 
tive  licensing  basis,  rather  than  selling  copies  outright. 

Another  important  difference  between  software  and  hardware  is  that  software  may  be  subject  to  a 
very  lengthy  lawful  monopoly  period  (i.e.,  the  approximately  75  year  period  of  a  copyright)  as  well 
as  being  held  as  a  trade  secret,  whereas  hardware  is  likely  to  be  subject  to  a  much  shorter 
monopoly  (i.e.,  the  seventeen  year  period  of  a  patent)  and  most  often  cannot  be  held  as  a  trade 
secret  since  reverse  engineering  of  the  hardware  would  likely  reveal  any  "secrets"  contained 
therein.  Quite  often,  in  fact,  hardware  is  either  not  patented  at  all  or  only  subject  to  partial  patent 
protection.  Patents  are  usually  difficult  to  get  because  of  the  high  standards  of  invention  that 
must  be  met,  whereas  copyrights  are  relatively  easy  to  obtain.  Hardware,  unlike  software,  cannot 
be  copyrighted  at  all.  Moreover,  software,  if  copyrighted,  will  also  be  subject  to  strict  limitations 
on  the  rights  of  the  user  to  make  derivative  works  from  the  software.  Hardware,  even  if  patented, 
is  not  subject  to  similar  limitations. 

The  main  point  here  is  that  because  of  the  great  breadth  and  length  of  the  copyright  monopoly  on 
software,  it  will  be  much  harder  to  get  competition  as  to  software  reprocurements  and  main¬ 
tenance  than  as  to  hardware.  A  oonsequence  of  this  is  that  it  is  even  easier  to  get  "locked  into"  a 
sole  source  position  as  to  software  than  as  to  hardware.  Because  the  government  is  becoming 
ever  more  dependent  on  software,  this  should  be  a  serious  concern. 

Also,  because  software  engineering  is  a  discipline  which  is  still  in  the  early  stages  of  its  develop¬ 
ment,  it  is  generally  more  difficult  to  specify  how  software  should  be  developed  for  particular 
functions  and  to  estimate  the  costs  and  development  schedule  for  it.  Software  is  also  virtually 
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"invisible"  as  compared  with  hardware,  which  means  that  it  is  more  difficult  to  detect  if  someone 
delivers  very  similar  or  nearly  identical  software  on  a  second  development  contract.  Further 
"invisibility"  means  that  It  may  be  more  difficult,  as  a  general  matter,  to  detect  defects  in  software 
or  to  know  how  to  fix  them  once  the  defect  is  known.  Again,  because  software  engineering  is  a 
developing  art,  software  is  likely  to  contain  a  lot  of  undetected  defects  that  will  need  to  be  cor¬ 
rected  while  in  the  user’s  possession.  Also,  unlike  hardware,  software  is,  in  general,  readily 
changeable;  new  capabilities  can  be  added  without  substantial  additional  costs.  All  of  this  tends 
to  make  software  maintenance  and  enhancement  a  much  more  substantial  part  of  software  life 
cycle  planning  than  may  be  the  case  with  hardware. 


2.  Software/Technical  Data 

Software  and  technical  data  are  similar  in  that  both  are  recorded  information.  They  are  also  alike 
in  that  both  are  often  held  as  trade  secrets,  and  licensed  under  restrictive  conditions,  rather  than 
being  sold  in  the  marketplace.  Loss  of  the  secrets  may  undermine  or  destroy  the  firm’s  commer¬ 
cial  advantage.  Both  are  also  capable  of  being  claimed  as  unpublished  copyright  material.  Both 
Involve  modest  production  costs  in  themselves  once  the  technology  they  embody  has  been 
developed.  Both  are  difficult  to  price  with  any  precision. 

Because  the  material  costs  are  low  (i.e,  what  it  costs  to  do  a  drawing  on  paper,  what  it  costs  to 
make  a  second  copy  of  software),  the  government  often  thinks  the  price  ought  to  be  low.  Be¬ 
cause  it  is  the  valuable  technology  that  they  embody  that  the  firm  wants  to  protect  and  exploit, 
industry  tends  to  price  them  high.  With  both  software  and  technical  data,  crucial  information 
necessary  for  maintenance  or  enhancement  of  the  item  to  which  they  pertain  may  not  be  readily 
apparent  from  examination  of  the  paper  or  disk;  rather  it  may  be  stored  away  in  the  memory  of 
some  engineer  who  designed  it.  Ongoing  service  contracts  are  sometimes  necessary  to  be  able 
to  gain  access  to  that  type  of  expertise. 

Where  software  differs  from  technical  data  is  in  being  an  "end  item"  in  itself.  Software  is  a 
product  that  will  perform  machine  functions,  whereas  technical  data  is  merely  information  about  a 
product.  As  an  end  item,  software  will  be  more  likely  to  be  a  product  with  a  commercial  market 
whereas  technical  data  will  often  not  be  sold  or  licensed  to  anyone  but  the  government.  When 
altered,  software  will  perform  differently,  as  compared  with  technical  data  which  will  simply  reflect 
a  new  configuration.  Software  also  requires  an  environment  of  equipment  and  other  software  to 
be  effective. 

B.  Getting  Adequate  Rights  and  Documentation  to  Maintain  and  Enhance 
Software 

The  DoD  has  been  experiencing  some  difficulty  in  acquiring  sufficient  rights  In  software  and 
software  documentation  to  enable  It  to  maintain  or  enhance  software,  either  in-house  (commonly 
referred  to  as  "organic  maintenance")  or  by  private  firms  through  competitive  bidding.  This  sec¬ 
tion  discusses  some  of  the  reasons  underlying  these  difficulties. 
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1.  Getting  Rights  to  Modify 


In  contrast  to  the  beliefs  of  many  who  have  addressed  DoD’s  software  procurement  problems, 
the  acquisition  of  the  rights  necessary  to  modify  software  is  not  a  current  software  licensing 
problem  of  the  Defense  Department.  While  many  other  buyers  or  licensees  of  software  are 
experiencing  difficulty  in  negotiating  with  software  firms  about  whether  or  not  they  or  persons 
whom  they  authorize  can  modify  software,  this  does  not  seem  to  be  DoD’s  problem.  The  DoD 
procurement  regulations  require  that  in  all  software  acquisition  contracts  the  government  must  get 
the  right  to  modify  the  software.1  Government  lawyers,  on  the  whole,  tend  to  think  that  this 
means  that  even  when  a  contract  between  the  government  and  a  software  contractor  is  silent 
about  modification  rights,  the  standard  data  rights  clause  will  be  construed  by  a  court  to  be 
incorporated  into  the  contract  under  the  Christian  doctrine.2  On  the  other  hand,  though,  some 
DoD  personnel  seem  to  believe  that  if  prime  contractors  negotiate  away  the  government’s  right  to 
modify  software  in  dealing  with  a  subcontractor,  the  government  would  be  bound  by  the  prime’s 
action.  This  may  not  in  fact  be  so,  although  the  law  is  uncertain  in  this  area. 

If,  instead  of  relying  on  the  DoD  standard  data  rights  clause,  the  government  were  to  rely  on  the 
copyright  law  as  a  basis  for  obtaining  rights  to  modify  software,  the  government  might  have  some 
serious  difficulties.  Copyright  law  regards  a  modification  of  copyrighted  software  as  the  creation 
of  a  "derivative  work"  for  which  one  would  need  the  permission  of  the  copyright  owner.3  Although 
there  is  a  limited  right  to  modify  software  under  Section  117  of  the  copyright  law,  the  right  is  so 
limited  as  to  be  virtually  nonexistent  (1)  because  only  "owners"  of  copies  (and  not  licensees)  have 
such  rights,  and  (2)  because  modifications  are  only  permitted  to  the  extent  they  are  created  as  an 
"essential  step  in  the  utilization  of  a  computer  program  in  conjunction  with  a  machine."  One  court 
has  interpreted  this  to  mean  that  modifications  are  only  permitted  if  the  program  won’t  execute  as 
is.4  Because  copyright  law  currently  offers  such  limited  rights  to  modify  software,  it  is  important 
that  DoD  has  made  modification  rights  part  of  the  package  of  minimum  rights  that  it  always  gets 
in  software. 

2.  Getting  Adequate  Documentation  To  Make  Modifications 

Getting  adequate  software  documentation  seems  to  be  the  major  software 
maintenance/enhancement  problem  the  Defense  Department  is  currently  having.  Many  of  DoD’s 
difficulties  seem  to  fall  within  one  of  the  following  categories  of  problems: 

(a)  companies  being  unwilling  to  give  their  source  code  or  other  proprietary  information  to  the 
government  at  any  price  or  under  any  conditions; 

(b)  the  need  to  be  farsighted  enough  to  ask  for  delivery  of  all  the  documentation  needed  to 
enhance  or  maintain  a  system; 

(c)  the  need  to  supervise  the  delivery  of  documentation  to  insure  that  everything  was 
delivered  that  should  have  been  delivered; 

(d)  the  need  to  supervise  the  attachment  of  restrictive  notices  to  software;  or 

(e)  difficulty  in  comprehending  the  documentation  delivered  because  of  its  complexity  or  tur- 
gidity. 
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There  seems  to  be  general  agreement  among  DoD  personnel  that  steps  need  to  be  taken  to 
remedy  this  situation.  Some  are  hopeful  that  solutions  can  be  devised  that  would  create  greater 
incentives  for  industry  to  voluntarily  cooperate  with  DoD  in  its  efforts  to  get  better  documentation 
for  maintenance  purposes.  Some  worry  that  punitive  approaches  could  enhance  already  strong 
disincentives  to  cooperate  with  the  government  in  this  respect.  The  possibility  of  the  government 
entering  escrowing  agreements  whereby  needed  documentation  is  placed  into  escrow  with  the 
government  to  have  access  to  the  documentation  on  an  as  needed  basis  upon  the  meeting  of 
some  certain  specified  condition(s)  precedent  is  a  potential  solution  which  holds  significant 
promise.  Such  arrangements  have  been  used  with  a  large  amount  of  acceptance  and  success 
within  private  industry. 


3.  Getting  Sufficient  Rights  In  Software  And  Documentation  To  Get  Competition 
As  To  Software  Maintenance  And  Enhancements 

Whether  the  government  can  get  competition  in  software  maintenance  and  enhancement  con¬ 
tracts  seems  largely  to  turn  on  whether  the  government  has  ownership  of  or  unlimited  rights  in 
software  and  its  associated  documentation,  or  whether  the  government  has  only  restricted  rights 
as  to  the  software  and  limited  rights  as  to  the  documentation.  If  the  government  has  ownership  or 
unlimited  rights,  getting  competition  in  software  maintenance/enhancement  contracts  appears  to 
be  relatively  easy.  If  instead  the  government  has  only  restricted  and  limited  rights,  it  seems  that 
getting  competition  is  very  difficult.  Defense  Department  personnel  generally  report  little  success 
in  getting  restricted  rights  software  competitively  maintained. 

As  the  DoD  regulations  are  presently  written,  while  DoD  virtually  always  has  rights  to  modify 
software,  it  does  not  automatically  have  rights  to  sublicense  the  modification  right  to  others.  That 
means  that  getting  competition  as  to  maintenance  and  enhancement  of  restricted  rights  software 
will  only  be  feasible  if  the  software’s  owner  will  agree,  which  he  need  not.  If  he  will  not  agree, 
DoD  will  either  have  to  do  the  modifications  itself  or  hire  the  original  firm  to  do  the  maintenance 
on  a  sole  source  basis. 

Because  many  software  companies  may  wish  to  have  sole  source  maintenance  contracts  with 
DoD,  their  Incentives  to  agree  to  competitive  maintenance  arrangements  are  minimal.  It  seems 
that  the  best,  and  perhaps  only  time  there  may  be  any  opportunity  to  get  such  agreements  to 
allow  competitive  maintenance  is  during  the  original  competition  when  the  development  contract 
is  let.  For  this  reason,  it  seems  imperative  that  DoD  personnel  involved  in  software  acquisition  be 
as  well  trained  and  prepared  as  possible  to  recognize  DoD's  maintenance  and  enhancement 
needs  so  as  to  increase  the  probability  that  they  will  be  able  to  secure  favorable  arrangements  at 
this  time  when  DoD’s  leverage  is  at  its  peak. 
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C.  Maintenance  Needs  For  Things  Used  In  Performance  of  Government 
Contracts:  Software  Tools  and  CAD/CAM  Programs 

Documentation  is  often  not  the  only  thing  needed  in  order  to  maintain  or  enhance  software. 
Access  to  software  tools  and/or  CAD/CAM  programs  may  also  be  needed  to  do  maintenance  and 
enhancement  work.  Indeed,  because  of  the  tremendous  commercial  value  of  software  tools  and 
CAD/CAM  programs,  as  well  as  the  usually  steep  development  costs,  it  may  be  even  more  dif¬ 
ficult  to  persuade  industry  to  make  these  valuable  items  available  to  the  government  than  it  would 
be  to  persuade  them  to  part  with  software  documentation.  In  addition,  industry  may  be  par¬ 
ticularly  sensitive  about  government  proposals  to  license  competitors  to  make  use  of  these  valu¬ 
able  technologies  since  these  items  will  often  be  a  part  of  the  companies’  competitive  edge  in  the 
market  place. 


1.  Software  Tools 

Software  tools  are  a  set  of  programs  that  may  be  used  in  the  production  of  other  programs. 
Software  tools  commonly  include  editors,  compilers,  and  debuggers,  among  other  things.  The 
application  software  produced  by  the  tools  could  be  anything  from  the  guidance  system  of  a 
missile  to  an  inventory  control  program.  Much  of  the  expensive  software  the  government  buys  is 
software  which  is  expected  to  be  modified  over  time.  For  example,  satellite  monitoring  systems 
must  be  revised  whenever  a  new  satellite  is  launched.  In  order  to  modify  application  software  in 
an  optimal  way  -and  in  some  cases,  in  order  to  modify  it  at  all  --  it  may  be  desirable  or  necessary 
to  have  access  to  the  software  tools  that  were  used  to  create  the  program  in  the  first  place. 

Even  if  the  government’s  procurement  personnel  have  the  foresight  to  try  to  bargain  to  obtain 
rights  in  software  tools,  the  company  may  be  extremely  reluctant  to  grant  anyone  -  let  alone  the 
government  (which  is  widely  perceived  by  industry  to  be  unable  to  protect  commercial  secrets)  - 
to  have  a  copy  of  the  software  tools,  or  even  to  have  access  to  the  tools.  A  software  producer’s 
tools  may  be  perceived  to  be  the  major  factor  in  the  company’s  competitive  edge  in  the  industry. 
In  addition,  the  development  of  such  tools  often  requires  a  substantial  inventment  on  the  part  of 
the  company,  an  investment  which  the  company,  understandably,  expects  to  be  able  to  recoup. 
Consequently,  making  such  items  available  to  the  government  is  often  a  highly  charged  subject. 
Indeed,  for  the  government  to  be  able  to  make  any  deal  to  get  proprietary  software  tools  is  offen 
thought  a  remarkable  event. 

One  potential  approach  to  this  problem,  as  was  also  mentioned  in  the  discussion  regarding 
documentation  above,  would  be  for  the  government  to  enter  into  an  escrow  agreement  with  the 
developer.  An  escrow  arrangement  could  be  structured  so  as  to  allow  the  government  access  to 
needed  tools  and  other  programs,  upon  the  meeting  of  some  specified  condition(s)  precedent, 
while  still  protecting  the  company’s  proprietary  information.  Moreover,  such  an  approach  would 
be  consistent  with  normal  commercial  practices. 

Another  potential  approach  to  this  problem  would  be  for  non-governmental  third  parties  to  enter 
into  licensing  arrangements  with  the  software  tool  producer  (assuming  that  the  company  would 
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license  anyone)  on  more  restrictive  terms  than  government  procurement  practices  would  allow. 
The  government  could  then  allow  this  third  party  licensee  to  do  the  maintenance/enhancement 
work.  This  may  not  be  a  viable  solution  in  some  instances,  however,  since  there  seems  to  be  a 
strong  preference,  if  not  a  clear  policy,  for  DoD  to  do  "organic"  maintenance/enhancement  work 
for  all  weapons  system  software  and  weapons  related  software.  It  also  seems  that  many  com¬ 
panies  would  not  license  proprietary  software  tools  to  anyone.  In  these  cases,  however,  the 
escrow  approach  might  still  be  available. 

Further,  it  should  be  noted  that  those  software  tools  which  are  made  available  to  the  government 
or  to  third  party  maintainers  are  likely  to  be  "older",  less  valuable  technologies.  The  government 
may  often  have  to  be  content  to  use  such  older  technologies  if  it  wants  to  have  unlimited  rights  in 
software  tools.  If  DoD’s  priority  is  to  get  the  best  technology,  using  old  tools  doesn’t  seem  to  be 
desirable.  If  DoD’s  priority  is  to  be  able  to  do  all  maintenance  and  enhancement  organically,  then 
having  rights  to  old  tools  is  better  than  having  rights  in  none. 


2.  CAD/CAM  Programs 

Increasingly,  industries  are  using  computer  aided  design/computer  aided  manufacturing 
(CAD/CAM)  programs  to  design  systems  of  many  sorts,  as  well  as  to  manufacture  them.  This 
seems  to  be  especially  true  with  regard  to  the  aircraft  industry.  Because  aircraft  tend  to  be  rather 
expensive  systems  and  systems  which  require  more  than  a  modest  amount  of  maintenance  and 
enhancement,  both  as  to  software  and  hardware  components,  there  is  growing  concern  within  the 
Defense  Department  about  getting  access  to  and  rights  in  the  CAD/CAM  programs  used  to 
design  the  systems  Initially.  Access  to  these  programs  may  be  essential  to  do  maintenance  and 
enhancement  work  for  the  system.  The  companies  that  have  developed  them  may  be  unwilling 
or  at  least  very  reluctant  to  give  the  government  any  rights  to  them,  or  to  authorize  third  party 
maintainers  to  have  access  to  them  because  of  their  great  commercial  value,  and  high  develop¬ 
ment  costs.  This,  therefore,  Is  another  area  where  use  of  escrowing  agreements  might  prove  a 
useful  way  for  the  government  to  gain  access  to  the  technology  necessary  to  fulfill  its  main¬ 
tenance  and  enhancement  requirements.  Arrangements  providing  for  access  to  such  tools, 
rather  than  actual  physical  possession  of  them,  are  often  more  acceptable  to  industry. 

D.  Other  Problems  With  Getting  Delivery  of  Adequately  Supportable 
Systems 

1.  Different  Interests  Of  Buyers  and  Maintainers  Within  the  Government 

There  also  appears  to  be  some  structural  problems  Internal  to  the  Defense  Department  that  may 
make  adequate  planning  for  software  maintenance  and  enhancement  difficult  to  achieve.  Major 
weapons  or  communication  systems  acquired  by  DoD  may  Include  complex  software  com¬ 
ponents.  These  systems  may  also  require  significant  and  complex  software  systems  to  support 
the  major  systems.  If  the  command  which  purchases  the  system  is  not  the  command  which  will 
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use,  maintain,  or  enhance  the  system,  it  may  not  be  aware  of  the  extent  of  software  documen¬ 
tation  that  will  be  needed  to  use,  enhance,  or  maintain  the  software,  and  it  may  not  be  as  sen¬ 
sitive  to  the  need  for  supportability  of  the  software  as  the  using  or  maintaining  command  might 
need  it  to  be.  Although  there  are  some  structural  mechanisms  within  DoD  that  are  intended  to 
provide  opportunities  for  communication  about  such  matters,  that  may  not  always  work  as  suc¬ 
cessfully  as  DoD  would  wish.  This  could  be  a  contributing  cause  toward  the  software  main¬ 
tenance  and  enhancement  problems  DoD  has  encountered. 


2.  Sole  Source  Maintenance  As  a  Habit 

From  procurement  personnel’s  point  of  view,  H  a  company  has  built  a  complex  piece  of  software 
for  DoD,  and  it’s  a  good  piece  of  software,  that  company  will  likely  know  that  software  better  and 
will  be  able  to  maintain  it  better  than  any  other  company,  even  if  the  other  company  gets  the 
source  code.  That  software  engineering  is  still  in  fairly  primitive  stages  as  an  engineering  dis¬ 
cipline  makes  reliance  on  the  original  developer  to  do  maintenance  work  often  seem  the  most 
expedient  route  to  take.  The  developing  company  will  have  a  better  idea  of  how  to  avoid  the 
problems  that  enhancing  one  section  of  a  program  can  so  often  create  in  another  part  of  code. 
Theoretically,  the  developing  firm  will  be  able  to  do  the  job  faster,  more  reliably,  and  more 
cheaply  than  a  competitor  because  they  won’t  have  to  be  brought  up  to  speed  on  it,  and  if  it’s  a 
good  piece  of  code,  then  the  developing  company  may  be  thought  to  deserve  to  reap  some  more 
rewards.  Besides,  procurement  personnel  may  be  wont  to  think,  we  already  know  those  guys 
and  they  do  a  good  job  for  us.  Quality  and  quickness  count  for  something;  money  isn’t  every¬ 
thing.  So  why  not  deal  with  that  company  instead  of  having  to  go  through  a  long  drawn  out 
competition  process?  Over  time,  the  original  developer  may  become  more  and  more  confident  of 
its  position  as  the  sole  source  for  maintenance,  and  may  increase  the  price  for  its  services  ac¬ 
cordingly.  It  may  thus  be  difficult  for  the  government  to  break  away  from  sole  source  main¬ 
tenances  no  matter  what  the  cost. 

If  one  adds  to  this  set  of  already  described  structural  disincentives  to  adequate  planning  for 
software  maintenance  and  supportability  the  fact  that  procurement  personnel  are  often  not  well 
trained  about  software,  system  lifecycles,  or  data  rights,  one  can  see  that  the  structural  problems 
internal  to  the  Defense  Department  may  be  significant  contributors  to  software  maintenance 
problems.  It  takes  considerable  sophistication  and  experience  with  major  systems  and  what  it 
takes  to  support  them  to  plan  for  system  supportability.  Adequate  planning  may  be  made  ad¬ 
ditionally  difficult  because  at  the  time  a  development  contract  is  let,  the  software  for  the  system 
will  often  not  yet  be  in  existence,  but  only  in  the  preliminary  planning  stages,  and  supportability  of 
the  software  system  will  likely  not  be  easily  plannable  until  after  the  system  is  more  fully 
developed. 

It  is  perhaps  an  obvious  point  that  the  structural  problems  internal  to  the  Defense  Department 
create  opportunities  in  software  maintenance  and  supportability  contexts  for  industry  to  charge 
very  large  sums  of  money  for  work  or  rights  that  could  have  been  purchased  more  cheaply  had 
they  been  bargained  for  at  the  early  phases  of  the  contractual  arrangement.  It  is  often  in  the 
industry’s  interest  to  take  advantage  of  these  opportunities  when  they  arise. 
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E.  Some  Recommendations  About  Licensing  Problems  Relating  To 
Maintenance  and  Enhancement  of  Software 

This  article  has  explored  various  problems  and  concerns  related  to  the  maintenance  and  en¬ 
hancement  of  software  acquired  by  DoD.  The  need  for  rights  to  modify,  and  the  need  for  access 
to  documentation  and  software  development  tools  has  been  discussed  at  some  length.  While  the 
acquisition  of  modification  rights  was  found  not  to  be  a  major  problem  for  DoD,  serious  difficulties 
with  respect  to  the  acquisition  of,  or  access  to  technical  documentation,  software  tools  and 
CAD/CAM  programs  was  discussed.  Some  potential  solutions  to  these  concerns  have  been 
suggested. 

The  primary  problem  areas  which  have  been  identified  herein  include: 

1)  The  need  for  DoD  to  develop  arrangements  whereby  companies  will  allow  it  access  to  com¬ 
mercially  valuable  software  development  tools  and  technical  documentation  the  contractor  would 
not  be  willing  to  give  up  physical  possession  of,  and 

2)  The  need  for  DoD  planning  and  procurement  personnel  to  be  aware  of  DoD’s  maintenance 
and  enhancement  needs  as  they  relate  to  software  development  tools  and  to  be  alert  to  strengths 
in  DoD’s  bargaining  position  in  this  regard  prior  to  the  actual  awarding  of  a  contract. 

The  following  set  of  specific  recommendations  are  offered  for  consideration  as  possible  solutions 
to  the  maintenance  and  enhancement  problems  discussed  in  this  article. 

1.  Getting  Adequate  Documentation  and/or  Software  Development  Tools 

(a)  Consider  entering  into  escrow  agreements  whereby  documentation  is  placed  in  the  hands 
of  a  third  party  with  the  documentation  to  be  released  for  use  by  the  government  only  upon  the 
meeting  of  certain  specified  conditions  as  another  possible  alternative  to  deal  with  maintenance 
and  enhancement  problems. 

(b)  Develop  a  better,  more  specific,  more  standardized  set  of  specifications  about  what 
documentation  must  be  delivered  to  DoD  and  with  what  rights. 

(c)  Decide  upfront  what  arrangements  the  government  wants  or  needs  to  make  about  who 
should  do  the  maintenance  or  enhancement  work.  For  reasons  other  than  merely  cost,  the 
government  may  need  to  do  the  maintenance  in-house.  How  much  rights  and  how  much  data  the 
government  needs  from  a  contractor  will  in  large  measure  depend  on  this  decision. 

(d)  Assess  the  relative  costs  of  acquiring  different  levels  of  rights  and  of  sole  source,  internal  or 
competitive  maintenance  over  time  so  that  cost-effective  choices  can  be  made  upfront.  Recog¬ 
nize  that  sometimes  sole  source  maintenance  will  be  cheaper  than  acquiring  all  the  rights  and 
data  needed  to  do  the  maintenance. 

(e)  Insist  that  procurement  personnel  involve  both  the  using  command  and  the  maintaining 
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command  in  the  supportability  planning,  perhaps  even  getting  engineers  from  these  latter  com¬ 
mands  to  sign  off  on  the  system. 

(f)  Train  procurement  personnel  about  software  life  cycle  needs,  about  data  rights,  and  about 
software  documentation  as  regards  supportability  needs. 


2.  Getting  Sufficient  Rights  To  Enable  Competition  For  Maintenance 

(a)  Recognize  that  it  may  be  difficult  to  impossible  to  compete  maintenance  and  enhancement 
of  software  held  as  a  trade  secret  by  its  owner.  Assess,  to  the  extent  you  can,  what  the  long  term 
maintenance  needs  and  costs  are  likely  to  be,  taking  into  account  what  cost  savings  may  be 
achievable  by  competition.  Remember  that  it  may  not  be  worthwhile  to  buy  rights  to  compete 
maintenance. 

(b)  Recognize  that  DoD’s  only  chance  to  get  competition  as  to  software  maintenance  may  be 
when  it  is  initially  negotiating  the  system  development  contract. 

(c)  If  DoD  decides  to  try  to  compete  the  maintenance,  it  should  recognize  that  it  will  need  to  get 
upfront: 

(i)  the  ability  to  sublicense  the  software  modification  right  or  a  commitment  by  the  contractor  to 
license  another  company; 

(ii)  the  ability  to  sublicense  its  rights  in  documentation  about  the  software  or  a  commitment  by 
the  contractor  to  license  the  other  company's  access  to  the  documentation; 

(iii)  very  detailed  documentation;  and  possibly 

(iv)  rights  in  the  software  tools,  or  a  commitment  from  the  developing  firm  to  license  a 
competitor's  access  to  the  tools. 

(d)  It  may  be  desirable  for  DoD  to  develop  a  standard  competitive  or  maintenance  license 
provision  and  clause  for  the  DoD  FAR  SUPP  in  order  to  alert  contract  officers  to  the  need  for  and 
the  appropriate  manner  of  obtaining  rights  for  these  purposes.  It  seems  unwise  to  rely  on  the 
existing  definition  of  "license  rights"  to  achieve  this  because  it  refers  only  to  licensing  for 
governmental  purposes  and  begs  the  question  whether  competitive  maintenance  and  enhance¬ 
ment  are  within  the  scope  of  the  "governmental  purpose"  language. 

(e)  To  be  able  to  maximize  the  possibility  of  gaining  agreement  for  competitive  maintenance  of 
proprietary  software,  DoD  should  be  prepared  to  make  arrangements  : 

(i)  either  to  name  who  will  be  the  third  party  maintainer  or  define  what  process  will  be  used  to 
qualify  a  potential  third  party  maintainer;  and 

(ii)  to  promise  the  developer  of  the  software  to  put  the  competitive  maintainer  under  a  specific 
set  of  restrictions  (such  as  those  under  which  the  government  operates  as  to  that  software). 


The  government  might  also  want  to  consider  naming  the  original  software  developer  as  a  third 
party  beneficiary  of  the  agreement  between  the  government  and  the  third  party  maintainer  as  to 
restrictions  on  rights  so  that  if  there  is  abuse,  the  developer  can  directly  sue  the  maintainer. 
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Notes 


’See  DoD  FAR  SUPP  sec.  52.227-7013(b)(3). 

2See  G.L.  Christian  and  Assoc,  v.  United  States,  160  Ct.  Cl.  1  (1963)  in  which  the  court  read 
"termination  (or  the  convenience  of  the  government"  clause  into  a  military  housing  contract. 

3See  17U.S.C.  sec.  106(2). 

4See  Midway  Mfg.  Co.  v.  Strohon,  564  F.  Supp.  741  (N.D.III.  1983). 
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